having some issues trying to run the quickstart for kratos and oathkeeper. seems that the

Requested url does not match any rules

error keeps showing up when i try to hit

<http://locahost:4455/welcome>

what are the

access-rules.yml

that you have set up with your oathkeeper instance?

so I am using the same one presented on the Github (though my editor is formatting it on save so could try turn that off) https://github.com/ory/kratos/blob/master/contrib/quickstart/oathkeeper/access-rules.yml

so.. maybe it's a typo but did you really mean:

<http://locahost:4455/welcome>

?

oh that was a typo, but let me try change all instances of 127.0.0.1 to localhost

don't do that

ahh ok, now I need to change the defaults on vscode the port forwarding using

localhost

but if was working for

127.0.0.1

🙂 love when it's a "me-problem", those I can fix.

yes same, first time getting Kratos + Oathkeeper working (using the standaolne-node-ui) so now trying to get these all pieced together with a Go project as well as Keto eventually.

incidentally, i have a fork of oathkeeper 😉 my fork adds a couple things i feel are missing: 1. oathkeeper's default regex engine for some reason does not allow (positive or negative) look-behinds, named captures, or effectively any regex that requires a '' or '' character (as it uses those two characters as delimiters for regular expressions within the

match

. My branch solves this. (tldr; updates the regex engine parser to support multi-byte delimiters) - Note, the regexp engine oathkeeper uses (dlclark/regexp2) already supports lookbehinds/named captures etc. The only thing preventing their use in oathkeeper is their unfortunate collision with the '' and '' characters as those are required to start look-behinds or named captures within a regular expression. 2. added

RegexpNamedCaptureGroups

to the

MatchContext

3. added

rule_id

to the

.MatchContext.Extra

as a string entry to the

Extra

field 4. fixed

RegexpCaptureGroups

to not include named captures (annoying when you expect the capture groups to simply be numbered and not include ones you've named) 5. feature: HMAC and JWKS payload signing on

remote

and

remote_json

authorizers. This is a big one for me. I have a use case where i have to hit some old legacy system that is open to the whole freaking world (nice design guys). So when I send "auth" requests, i need a way for the boneheads to be able to verify / validate the request, indeed, came from "me" (as othkeeper). So i added the ability for oathkeeper to "sign" the payload using configured jwks keys or just a simple HMAC shared key if desired. The endpoint can verify the jwks key by checking the

.well-known/jwks.json

of a pre-populated

issuer

url (my oathkeeper public issuer) (and oathkeeper populates a

...-Kid

header for them to know which

kid

signed the payload.